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Abstract 

The  Dual-radar  Software  Development  Facility  Project  is  an  example  of  the  collaborative 
efforts  required  between  an  Air  Force  System  Program  Office,  a  Air  Force  Logistics 
Center,  the  Air  Force  Research  Laboratory,  the  Air  Force  Special  Operations  Command, 
The  Contractor  Raytheon,  and  the  Contractor  Boeing  to  provide  a  common  (inter¬ 
operable)  embedded  information  support  environment  for  multiple  weapon  systems.  This 
paper  will  provide  a  case  study  of  the  multiple  programs  (along  with  their  associated 
histories)  leading  up  to  the  realization  of  the  Dual-radar  Software  Development  Facility. 

The  Dual-radar  Software  Development  Facility  supports  the  radar  software  for  both  F-15 
APG-70  and  AC-130U  Gunship  APQ-180  Radars.  The  provision  of  a  common  support 
environment  was  proven  feasible  because  the  APQ- 1 80  radar  is  a  derivative  radar  of  the 
APG-70,  with  several  common  components.  The  DrSDF  program  followed  the  Advanced 
Avionics  Multi-Radar  Software  Support  System  (I  &  II)  that  first  provided  a  feasibility 
study,  and  then  provided  the  preliminary  engineering  designs  for  the  DrSDF. 

The  Aerospace  Command  and  Control  and  Intelligence,  Surveillance,  and 
Reconnaissance  (C2ISR)  Campaign  Plan  2000  has  a  focus  area  called  ISR  Sensors  and 
Platforms:  The  focus  area  states  we  need  to  invest  in  Global  Air  Traffic 
Management/Global  Air  Navigation  System  (GATM/GANS)  for  selected  C2ISR 
platforms  to  sustain  and  modernize  the  fleet.  This  investment  enhances  our  ability  to  meet 
the  high  demand  for  this  capability  throughout  multiple  Areas  Of  Responsibility  (AORs). 
We  need  to  deliver  an  effective  and  affordable  ISR  force  mix  fielding  plan.  This  plan 
must  determine  the  sensors  and  platforms  required  for  achieving  an  optimum  sensor  mix 
and  savings  in  concert  with  Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  Tasking 
Processing  Exploitation  and  Dissemination  (TPEDS)  Focus  Area. 


This  paper  will  provide  valuable  lessons  learned  through  its  history  of  providing  a 
capability  to  support  multiple  radar  sensor  platforms.  These  lessons  come  from:  (1)  the 
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program’s  early  feasibility  study,  (2)  the  assembling  of  multiple  disciplined  integrated 
product  teams,  (3)  the  collaborative  engineering  that  occurred  between  the  5  member 
engineering  organizations,  and  (4)  the  ultimate  multiple  of  platform  support  capability 
that  DrSDF  will  provide.  The  paper  will  also  show  how  these  lessons  will  provide  insight 
in  providing  the  Air  Force  an  effective  and  affordable  ISR  force  mix  fielding  plan. 

1.  Focus  Area:  ISR  Sensors  And  Platforms 

The  ISR  Sensors  and  Platform  issue  is  what  are  the  appropriate  investments  in  Air  Force 
owned  and  non- Air  Force  owned  capabilities,  with  emphasis  on  Theater  Air  Surveillance, 
Theater  Ballistic  Missile  Defense,  and  Ground  Target  Surveillance  to  support  real-time 
targeting  and  execution  of  the  air  war?  The  factors  affecting  this  issue  are: 

ISR  assets  are  in  high  demand;  coverage  is  required  throughout  multiple  AORs 
Allied  Force  Lessons  Learned  stress  the  need  to  support  the  JFACC’s  real  time 
precision  targeting  requirements 

Rapid  and  accurate  surveillance  needed  to  support  early  engagement 
Dynamic  sensor  tasking  required  for  time  critical  targeting 

The  consequences  (without  an  integrated  ISR  investment  strategy)  related  to  Sensors  and 
Platforms  are: 

There  will  be  insufficient  ISR  assets  to  meet  demands,  resulting  in  high  op  tempo  and 
degraded  ISR  capabilities 

DoD  will  continue  to  invest  limited  ISR  dollars  in  stove-piped  solutions 

The  Air  Force  will  continue  to  have  difficulty  identifying  and  striking  time  critical 

targets  (The  CSAF's  guidance  to  focus  on  time  critical  targets  will  not  be  met) 

This  excerpt  is  from  the  United  States  Air  Force  Aerospace  Command  Control 
Intelligence  Reconnaissance  (C2ISR)  Campaign  Plan  2000  [2]. 

2.  Airborne  ISR  Sensors  And  Platforms  Require  Complex  Infosphere  Development 
Environments 

Recently,  a  major  factor  in  providing  sufficient  ISR  assets  was  the  Software 
Development  Facility  (SDF).  The  SDF  allowed  complex  sensor  systems  to  be  fine-tuned 
and  upgraded  to  address  (or  better  address)  the  constantly  changing  threats  found 
throughout  the  world.  The  main  drawback  to  the  SDF  approach  is  that  they  are  primarily 
dedicated  to  specific  complex  sensors  and  weapon  platforms,  requiring  costly 
investments  in  overhead  support  equipment  and  highly  skilled  people. 

3.  AAMRSSS  and  DrSDF,  A  Case  Study  of  Interoperability 

The  Software  Development  Facility  (SDF)  has  evolved  as  a  sophisticated  environment  to 
develop  and  maintain  complex  weapon  system  embedded  software.  The  SDF  not  only 
must  provide  the  tools,  methodologies,  and  processes,  but  also  sophisticated  simulations 
and  emulation  of  the  system  under  test  and  its  real  time  environment,  plus  a  means  to 


record,  replicate,  operate,  and  analyze  the  embedded  system  software.  On  an  individual 
system  basis,  the  provision  of  an  SDF  is  expensive.  Because  of  this  expense,  it  would 
make  sense  to  jointly  utilize  SDFs  that  could  be  adapted  to  support  two  or  more  dedicated 
software  embedded  systems. 

The  idea  of  using  a  common  support  environment  to  develop,  maintain,  and  test  weapon 
system  embedded  information  is  not  new.  When  there  is  a  downsizing  of  weapon  system 
fleets,  a  deactivation  of  support  facilities,  or  an  introduction  of  a  new  system  or 
subsystems.  There  often  follows  a  re-examination  of  the  support  assets  and  how  those 
assets  can  best  be  utilized  or  supplemented  to  give  the  necessary  service  wide  (or  DOD 
wide)  life-cycle  support.  This  re-examination  often  makes  suggestions  on  how  assets 
could  be  jointly  used  to  provide  the  necessary  support  of  the  targeted  weapon  systems.  It 
is  from  these  re-examinations,  that  a  much  more  detailed  study  has  to  be  made  in  order  to 
assess  the  feasibility  of  going  to  a  common  support  environment.  This  study  actually 
compares  every  component,  function,  process,  and  politic  for  a  high  degree  of 
commonality.  A  serious  mismatch  of  any  one  of  these  parameters  could  easily  disqualify 
a  common  venture. 

It  should  be  clear  by  now  that  the  most  successful  attempts  for  common  support  are  those 
that  are  designed  to  be  so  from  the  beginning.  Weapon  systems  or  subsystems  that  are 
close  variants  of  each  other  and  based  on  high  commonality  of  components  and 
functionality  are  best  candidates  for  common  support.  Better  yet,  is  a  holistic  design, 
which  extends  to  the  weapon  system’s  overall  life-cycle  and  includes  the  support 
environment  as  well  as  links  to  closely  related  systems  and  subsystems.  It  is  rare  that 
multiple,  fielded  weapon  systems  can  share  a  support  environment.  This  is  because,  they 
have  developed  their  own  special  support  requirements,  and  their  configuration 
management  has  evolved  around  different  circumstances.  Later  on  in  this  paper,  a 
multiple  fielded  weapon  system  program  called  Advanced  Avionics  Multi-Radar 
Software  Support  System  (AAMRSSS)  will  be  presented  which  is  successful. 
AAMRSSS’  main  reason  for  success  is  that  the  two  Radar  Operational  Flight  Programs  it 
will  support  are  derivative  Hughes  Radars,  the  APG-70  and  the  APQ-180,  which  will  be 
jointly  supported  in  the  Warner  Robins  Air  Force  Base’s  F-15  Radar  Software 
Development  Facility  (SDF). 

Concurrency  of  common  resources  is  a  critical  issue  when  investing  in  a  multiple  support 
environment.  The  decision  to  implement  a  common  support  environment  is  heavily 
based  on  the  cost  savings  from  using  common  resources.  If  the  commonality  is  not 
managed  and  maintained,  the  strains  of  reconfiguring  between  weapon  system’s  upgrades 
could  compromise  the  efficiency  of  the  support  environment.  This  multi-configuration 
management  requirement  imposes  an  additional  support  cost  on  the  weapon  systems, 
which  must  be  considered  during  requirement's  analysis  and  reviewed  throughout  the 
systems  lifecycles. 

System  obsolescence  is  a  growing  concern  amongst  weapon  system  maintainers.  As  the 
age  of  the  weapon  system  and  its  sub-systems  increases,  the  demand  for  spare  parts, 
creative  substitutes,  and  replacement  becomes  increasingly  critical.  This  is  not  only  true 


for  the  weapon  system  and  its  sub-systems,  but  for  its  support  environment  and  the 
methods  and  processes  involved  in  keeping  it  current.  A  multiple  support  environment 
can  take  advantage  of  resolving  these  critical  obsolescence  situations  for  the  common 
components,  but  also  absorb  the  costs  of  the  multiple  weapon  systems  peculiar 
component  aging  and  shortage. 

The  expansion  of  the  software  development  facility  to  handle  additional  workload 
impacts  the  priority  of  the  individual  weapon  systems  as  well.  How  much  is  too  much? 
What  is  the  support  saturation  of  the  facility?  Are  there  additional  feasibility  issues  that 
must  be  addressed  before  proceeding  with  expansion?  The  conditions  and  resources  that 
made  a  shared  facility  possible  at  one  point,  could  very  well  change.  Expansion 
feasibility  studies  should  become  a  common  practice  of  the  shared  facility. 

The  degree  of  test  coverage  for  each  of  the  weapon  systems  is  an  important  aspect  of  the 
shared  facility.  This  determines  the  allocation  of  the  common  testing  resources,  as  well 
as  their  priority,  and  defines  the  unique  testing  resources  for  the  individual  weapon 
system’s  unique  characteristics. 

During  the  feasibility  study  phase,  a  have-to-have  analysis  should  be  performed.  That  is, 
what  does  each  weapon  system  have  to  have,  in  order  to  be  properly  supported  by  the 
shared  facility.  For  weapon  system  software  support,  this  will  include  a  software 
maintenance  environment  as  well  as  the  simulation  and  testing  resources  needed  to 
exercise  the  software  as  robustly  as  possible. 

The  weapon  system  software  maintainers  are  highly  skilled,  but  also  highly  specialized 
scientists  and  engineers.  As  the  common  facility  expands,  the  ability  to  utilize  evolving 
technology  and  to  stay  technically  current  must  be  provided  to  these  maintainers. 
Overlapping  skills  for  multiple  weapon  systems,  as  well  as  system  peculiar  skills  must  be 
added,  exercised,  and  evaluated  against  the  full  capability  of  the  shared  support 
environment. 

Where  a  peculiar  requirement  (or  skill)  is  implemented  (or  modified),  it  will  have  an 
impact  on  the  overall  support  capability.  Expanded  functionality  for  one  weapon  system 
will  require  additional  resources  of  some  type.  The  overall  capacity  to  provide  these 
resources  will  have  to  be  addressed. 

Floor  space  is  a  constant  concern,  when  more  than  one  entity  is  concerned.  How  many 
squares  are  available?  A  good  floor  plan,  ample  heating-cooling,  and  power  provisions 
are  factors  to  frequently  review. 

2.1  Advanced  Avionics  Multi-  Radar  Software  Support  Study  (AAMRSSS) 

The  first  phase  of  the  Advanced  Avionics  Multi-Radar  Software  Support  Study 
(AAMRSSS)  studied  the  feasibility  of  using  a  common  Software  Development  Facility 
(SDF)  to  support  multiple  software  system  platforms,  specifically  the  F-15  Eagle  and  the 
AC-130U  Gunship.  The  APG-70  Radar  in  the  F-15  Eagle  and  the  APQ-180  Radar  in  the 


AC-130U  Gunship  have  a  high  degree  of  LRU  commonality  despite  the  different 
missions  of  their  respective  weapons  systems.  The  time  critical  natures  of  these  radars 
and  their  diverse  functionality  have  been  addressed  in  this  Air  Force  sponsored  study 
with  Raytheon  Aircraft  Company.  Additionally,  through  the  separate  sponsorship  of  the 
Gunship  SPO,  Rockwell  North  American  (now  Boeing)  participated  in  the  study  reviews 
as  the  prime  contractor  for  the  AC-130U  Gunship.  Through  this  study,  an  approach  was 
developed  to  leverage  a  common  OFP  support  facility  for  both  radars.  Key  issues 
included:  differences  in  the  missions  of  the  weapons  systems,  the  aircraft  performance, 
the  radar  modes,  and  the  avionics  suite;  and  the  nature  of  the  radar  environment  and  real¬ 
time  radar  return  data  generation.  This  section  summarizes  the  issues  encountered  in  the 
study’s  investigation,  and  the  features  of  both  the  radars  and  the  support  needs  that  have 
influenced  the  design  of  a  shared  OFP  support  environment. 

The  F-15  Eagle  weapon  system,  with  the  APG-70  Radar  has  been  operationally  deployed 
much  earlier  than  the  Gunship  with  an  APQ-180  radar,  and  had  already  implemented  an 
APG-70  SDF.  This  facility  provides  capabilities  for  systems/software  analysis,  software 
development,  and  system  integration  and  test.  These  capabilities  are  supported  by  three 
major  subsystems:  the  Central  Development  Facility  (CDF),  the  system  test  benches 
(ASB  and  70RTBS),  and  the  Instrumentation  Data  Reduction  and  Analysis  System 
(IDRAS).  Figure  1  illustrates  these  subsystems  and  their  associated  capabilities. 

The  proposal  to  share  a  common  support  environment  between  the  F-15  APG-70  and  the 
Gunship  APQ-180  derives  benefits  from  a  common  architectural  heritage.  Figure  2 
illustrates  the  Line  Replaceable  Units  (LRU)  of  the  Gunship  APQ-180  radar.  Common 
processes,  methods,  and  tools  were  utilized  in  the  development  of  the  F-15  APG-70 
Radar  and  the  Gunship  Radar.  Both  radars  utilize  common  processors  (radar  signal  proc¬ 
essors  and  radar  data  processors)  that  utilize  Mil-  Std-1750A  instruction  set  architectures 
for  data  processing  and  control  functions.  With  the  minor  exception  of  OFP  built 
executives,  the  CDF  and  IDRAS  support  areas  that  can  be  used  in  common  across  both 
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Figure  2  -  Line  Replaceable  Unit  Components  of  the  AC-130U  Gunship’  Radar 


application  systems.  The  primary  area  impacted  by  the  proposed  multi-platform  support 
environment  is  that  of  the  system  test  benches. 

The  system  test  benches  are  significantly  impacted  by  the  application  specific 
requirements  of  the  supported  platform’s  mission  and  system  interfaces  of  the  avionics  to 
be  supported.  Environment  and  ownship  simulations  used  in  the  system  test  benches,  as 
well  as  test  equipment  interfaces  are  affected  by  this  application  specific  requirements. 
Figure  3  illustrates  and  summarizes  the  system  test  support  components  that  have  been 
addressed  in  the  system  test  support  of  the  APG-70  and  APQ-180  Radars. 

Cost-effective  weapons  systems  support  is  critical  in  the  current  fiscal  environment,  and 
has  been  a  key  concern  in  the  deployment  of  the  AC-130U  Gunship.  Since  the  Gunship’s 
APQ-180  Radar  uses  the  same  processor  suite  and  OFP  architecture  as  the  F-15  Eagle’s 
APG-70  Radar,  an  attractive  opportunity  exists  to  reduce  cost  by  leveraging  support 
systems.  Basic  radar  support  requirements  are  well  understood  at  this  time  and  a  multi¬ 
platform  support  environment  approach  has  been  identified  as  an  important  strategy. 

Improvements  in  the  test  capabilities  for  the  air-to-ground  radar  modes  critical  to  the 
Gunship  mission,  as  well  as  the  extension  of  automated  test  capabilities  to  improve  test 
bench  utilization,  became  the  focus  of  second  phase  study  efforts  (AAMRSSS2). 

Three  test  support  areas  were  identified  for  improvement  of  the  fidelity  of  air-to-ground 
test  of  the  radar  OFP:  the  Analog  Target  Generator  (ATG),  the  Digital  Target  Generator 
(DTG),  and  a  Digital  Play  Back  System  (DPBS).  The  target  generators  (i.e.,  ATG  & 
DTG)  are  SDF  test  support  products  that  are  to  be  upgraded  for  support  of  the  Gunship 
modes.  The  playback  system  (DPBS)  is  a  new  capability  leveraging  current  SDF  assets 
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Figure  3  -  DrSDF  System  Under  Test 


to  provide  for  the  playback  of  instrumented  flight  data  into  the  processors  of  the  radar  test 
bench. 

The  ATG  provides  RF  signals  to  the  radar  front-end  to  simulate  various  radar  target 
scenarios.  Technology  improvements  in  the  ATG  are  driven  by  the  radar’s  High 
Resolution  Map  (HRM)  and  Ground  Moving  Target  Track  (GMTT)  requirements  for 
much  improved  update  rates  and  enhanced  mainlobe  clutter  modeling. 

The  DTG  provides  digital  radar  return  samples  (i.e.,  I/Q  data)  to  the  radar  signal 
processor  as  they  would  be  sent  by  the  radar  front-end.  Technology  improvements  to  the 
DTG  provide  enhanced  ground  return  simulation  with  clutter  modeling  based  on  simple 
terrain  surfaces. 

Target  generators  as  used  in  the  SDF  are  based  on  simulation  models  that  have  limited 
fidelity  with  respect  to  the  complexities  of  the  real  world.  In  general,  these  models  allow 
the  performance  of  the  OFP  and  the  radar  to  be  validated  against  their  design  models. 
However,  validation  of  the  model  design  itself  is  limited.  The  DPBS  extends  the  test 
capabilities  of  the  SDF  radar  test  bench  to  validate  mode  design  against  full  fidelity  real 
world  conditions,  by  providing  the  ability  to  use  instrumented  flight  data.  This  capability 
allows  the  SDF  to  support  the  Gunship  APQ-180  testing  with  a  pre-recorded  suite  of 
missions,  as  well  as  the  ability  to  exhaustively  investigate  new  conditions. 

Automated  test  is  currently  supported  on  the  SDF  radar  test  benches  through  the  use  of 
the  Automated  Verification  &  Test  System  (AVTS),  a  scripted  test  system  that  is  layered 
on  top  of  the  GUI’s  of  the  test  bench.  Extensions  to  the  AVTS  enabling  support  of  the 
Gunship  were  evaluated  and  planned  to  improve  the  shared  utilization  of  the  SDF. 
Notable  other  improvements  to  support  the  Gunship  included  the  incorporation  of  the 
Gunship  battle  management  controls  and  automated  access  to  display  imagery  [3-11]. 


2.2  The  Dual  Radar  Software  Development  Facility  (DR  SDF) 

The  multi-use,  multi-platform  support  facility  defined  by  the  AAMRSS  Studies  and 
subsequently  developed  under  an  IPT  composed  of  the  AC-130U  Gunship  SPO,  Air 
Force  Special  Operations  Command  (AFSOC),  Warner  Robins  Air  Logistics  Center 
(WR-ALC),  Air  Force  Research  Lab  and  the  Raytheon  contractor;  is  known  as  the  Dual 
Radar  Software  Development  Facility  (DR  SDF).  This  facility  leverages  the  capabilities 
of  the  existing  F-15  SDF  at  WR-ALC  and  integrates  the  necessary  enhancements  to 
provide  effective  support  of  both  the  F-15  Eagle  APG-70  radar  and  the  AC-130U 
Gunship  APQ-180  radar. 

The  DR  SDF  development  program  is  currently  on-going  and  is  also  providing  parallel 
support  to  an  on-going  Boeing/Raytheon  APQ-180  radar  upgrade  program.  DR  SDF  test 
support  products  described  earlier  under  the  AAMRSSS  discussion  are  being  used  to 
assist  in  the  current  radar  upgrade.  In  addition,  a  Digital  Instrumentation  System  (DIS)  is 
being  integrated  into  the  AC-130U  Gunship  to  provide  full  bandwidth  collection  of 
baseline  flight  instrumentation  data  as  well  as  developmental  flight  test  data.  The  DIS 
provides  for  full  bandwidth  digitized  radar  return  data  for  performance  analysis  of  the 
Gunship  air-to-ground  radar  modes,  as  well  as  instrumentation  of  associated  avionics  I/O 
data.  This  data  will  also  be  available  for  later  use  with  the  DPBS  previously  described. 

3.  The  Joint  Battlespace  Infosphere 


Figure  4  -  The  JBI  Domain 

The  executive  summary  of  the  United  States  Air  Force  Scientific  Advisory  Board  Report 
on  “Building  the  Joint  Battlespace  Infosphere”  [1]  defines  the  Joint  Battlespace 
Infosphere  (JBI)  is  a  combat  information  management  system  that  provides  individual 
users  with  the  specific  information  required  for  their  functional  responsibilities  during 
crisis  or  conflict.  The  JBI  integrates  data  from  a  wide  variety  of  sources,  aggregates  this 
information,  and  distributes  the  information  in  the  appropriate  form  and  level  of  detail  to 
users  at  all  echelons.  The  JBI  was  originally  described  in  the  1998  USAF  Scientific 


Advisory  Board  (SAB)  report  Information  Management  to  Support  the  Warrior.  At  the 
joint  task  force  (JTF)  commander’s  level,  the  JBI  is  a  powerful  command  and  control  (C 
2  )  system  that  combines  inputs  from  a  variety  of  sources,  including  existing  C  2  systems, 
reconnaissance  data,  satellite  data,  unit  capability  data,  logistics  data,  and  real-time 
battlefield  conditions.  The  JBI  builds  an  aggregated  picture  from  these  combined  inputs, 
giving  unparalleled  situational  awareness  accessed  as  easily  as  a  web  page.  The  JBI  also 
provides  for  speedy  downward  flow  of  information,  so  when  commanders  order  an 
action,  the  action  is  received  and  implemented  at  the  subordinate  level  almost 
immediately.  The  commander  in  chief  (CINC)  or  JTF  commander  creates  a  JBI  for  a 
specific  purpose,  usually  in  response  to  a  crisis  or  conflict.  The  JBI  enables  the 
commander  to  focus  information  support  for  a  specific  operational  purpose,  ensure  or 
limit  access  to  critical  information,  and  provide  an  information  management  system  that 
can  respond  to  natural  or  enemy  actions  that  disrupt  communications  capabilities.  As 
units  are  assigned  to  the  mission,  their  information  needs  are  electronically  identified,  and 
available  information  is  automatically  accessed.  Thus,  deployed  units  are  ready  to  fight 
immediately  upon  being  deployed  or  assigned  [1], 


Supporting  these  capabilities  and  forming  a  foundation  of  the  JBI  is  a  platform  of 
protocols,  processes,  and  common  core  functions  that  permit  participating  applications 
and  organizations  to  share  and  exchange  critical  mission  information  in  a  timely  manner. 
It  provides  uniform  rules  for  publishing  new  and  updated  objects  into  the  JBI  and 
promptly  alerts  any  JBI  clients  that  have  subscribed  to  such  objects.  These  properties 
enable  dynamic  information  flows  among  client  programs  of  the  JBI,  serving  to  integrate 
the  clients  to  conduct  a  single  mission.  The  JBI  platform  integrates  many  individual 
information  systems  that  currently  support  operational  forces.  Each  existing  system  has 
been  developed  in  a  stove-piped  fashion;  few  interoperate  with  each  other.  The  JBI  acts 
as  an  intermediary  between  these  systems,  converting  information  from  one 


representation  to  another  to  enable  interoperability.  In  addition  to  acting  as  middleman 
between  disparate  systems,  the  JBI  interprets  the  information  flowing  between 
applications,  using  it  to  build  its  own,  more  complete,  picture  of  the  current  situation. 
Furthermore,  the  JBI  tailors  this  picture  for  individual  users:  the  commander  gets  a  high- 
level  view  of  the  campaign,  while  the  soldier  in  the  field  gets  a  detailed  description  of  a 
nearby  hostile  base.  The  JBI  provides  an  architecture  for  the  incorporation  of  future  data 
capture  technologies  that  exploit  better  sensors,  databases,  fusion  engines,  automated 
analysis  tools,  collaborative  planning  and  execution  aides,  and  distribution  controls.  It  is 
also  a  disciplined  process  that  guides  the  activities  of  people  responsible  for  obtaining, 
verifying,  fusing,  presenting,  analyzing,  and  controlling  the  information  necessary  for 
success  in  any  operation  [1], 

The  JBI  is  connected  to,  and  interoperable  with,  a  variety  of  existing  and  planned  C  2  and 
combat  support  information  systems.  The  JBI  is  not  intended  to  replace  C  2  systems,  but 
to  be  the  substrate  for  integrating  them.  The  JBI  subscribes  to  pertinent  information 
published  by  supporting  systems  and,  when  necessary,  pulls  specific  information  from 
other  networks.  In  addition,  the  JBI  connects  to  fusion  engines  and  may  perform  fusion 
on  its  own,  thereby  ensuring  that  the  most  complete  and  coherent  picture  of  the  battlefield 
situation  resides  within  the  JBI  itself.  The  JBI  concept  recognizes  that  display  technology 
is  constantly  advancing  and  that  new  displays  must  be  tailored  for  users  from  flight  leader 
to  JTF  commander.  The  JBI  provides  services  through  a  federation  of  multiple  servers. 
The  Global  Information  Grid  connects  these  servers  to  each  other  and  to  the  many 
systems  that  support  the  JBI.  Many  of  the  servers  provide  services  from  the  rear  via 
reachback,  thereby  limiting  the  forward  footprint  of  the  JBI  [1], 


Figure  6  -  JBI  Architecture 


4.  Summary  and  Conclusions 


The  consequences  (without  an  integrated  ISR  investment  strategy)  related  to  Sensors  and 
Platforms  are: 

There  will  be  insufficient  ISR  assets  to  meet  demands,  resulting  in  high  op  tempo  and 
degraded  ISR  capabilities 

DoD  will  continue  to  invest  limited  ISR  dollars  in  stove-piped  solutions 

The  Air  Force  will  continue  to  have  difficulty  identifying  and  striking  time  critical 

targets  (The  CSAF's  guidance  to  focus  on  time  critical  targets  will  not  be  met) 

A  way  to  provide  sufficient  ISR  assets  is  to  take  advantage  of  those  assets  that  have 
similar  support  environments.  It  has  been  estimated  that  75%  of  a  weapon  system’s 
(including  ISR  assets)  lifecycle  costs  is  that  of  support.  Leveraging  multiple- support 
platforms  increases  the  assets  available. 

Another  name  for  stove-piped  solutions  is  a  band-aide  approach.  Both  stove-piped  and 
band-aide  approaches  to  ISR  platforms  come  from  the  mentality  of  making  due.  Fly  the 
system,  and  fix  it  when  it  breaks.  Leveraging  multiple  assets  gives  each  asset  the  benefit 
of  the  other,  and  allows  the  combined  assets  to  place  an  emphasis  on  pre-emptive  life- 
cycle  issue. 

The  use  of  a  multiple  platform  support  environment  brings  together  domain  experts  from 
different  area.  The  combination  of  these  skills  might  provide  the  opportunity  to  address 
time  critical  targets  from  a  different  and  fresh  perspective. 

The  lessons  learned  from  the  Dual  Radar  Software  Support  Facility  (DrSDF)  program 
and  it  predecessor  programs  (Advanced  Avionics  Multi-Radar  Software  Support  System  I 
&  II)  guide  the  way  for  providing  similar  support  to  C2ISR  assets.  These  programs 
provide  rich  lessons  in  leveraging  commonality,  designing  for  commonality,  and  in 
multiple  organization  engineering  (collaborative  engineering)  efforts. 
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